Skip to main content
Feedback

6.3.0 Boomi Cloud API Management – Local Edition August 2026 Release Notes

Deploying this release on-prem requires the following supported component versions:

  • Kubernetes: 1.36 or Red Hat OpenShift: 4.21
  • Docker Engine: 29.6.0 or Podman: 5.8.4
  • Helm: 4.2.2

For Quickstart deployments only, use one of the following:

  • Rancher Desktop: 1.23
  • Docker Desktop: 29.6.0 or Minikube: 1.38.1
August 28 2026
New
We added these features

  • Added a migration utility from 5.x.x untethered to 6.3.0 tethered. This migration lets you move directly from an untethered Local Edition 5.x.x (end of life) environment to a tethered Local Edition 6.3.0 environment connected to Boomi Cloud API Management (SaaS). The migration tool runs inside your existing APIM 5.x.x environment and migrates all entities. The migration pod can now be deployed on Docker Swarm in addition to Kubernetes. (EIN-22694)

    Refer to Migrating from 5.x.x to 6.3.0 (untethered → tethered) in the Migration and Upgrade Guide for more information.

  • The migration pod now supports deployment on Docker Swarm, in addition to Kubernetes. You can deploy the migration pod on the infrastructure that matches your APIM 5.x.x source cluster, regardless of your target 6.x.x infrastructure. (EIN-23786)

    Refer to the Deploy migration pod on 5.x.x cluster in the Migration and Upgrade Guide for more information.

  • Boomi Cloud API Management – Local Edition (Tethered mode) now supports processing GraphQL requests through Traffic Manager, aligning with existing functionality in Boomi Cloud API Management. Traffic Manager can now parse, validate, and route GraphQL requests to your configured backend GraphQL server. This applies only to Tethered mode. GraphQL is not supported in Untethered mode. (EIN-23180)

    The configuration experience stays the same. You can continue to configure GraphQL endpoints on the Control Center's Key & Method Detection page the same way you already do for REST, SOAP, JSON-RPC, and XML-RPC endpoints.

    Refer to Configuring API Endpoint Key and Method Detection Settings for configuration steps, and to the GraphQL section in Endpoint Key and Method Detection for the complete list of configuration properties and HTTP error codes.

  • Boomi Cloud API Management – Local Edition now supports the OAuth2 Backend Authentication Policy to secure target requests using OAuth 2.0 access tokens, matching existing support in Boomi Cloud API Management.

    You can now configure the policy in Local Edition using the same area encryption key and endpoint configuration as Boomi Cloud API Management. To use it, set Values.global.areaEncryption to true in 6.3.0 values.yaml, then provide the area key and secret as a Kubernetes secret. (EIN-23179)

    Refer to Creating an Area Encryption Key in Local Edition and to the Values.global.areaEncryption section in 6.3.0 values.yaml within the Installation Guide for more information.

  • Boomi Cloud API Management – Local Edition now supports the Circuit Breaker Policy to provide a fail-safe mechanism for your APIs. This policy was previously available only in Boomi Cloud API Management (SaaS). You can now configure circuit breaker policies at both the service and endpoint levels, giving you granular control over your APIs' recovery and stability. (EIN-23175)

    Refer to Configuring Call Transformations in Policy UI and Configuration Values for more information. (EIN-23619)

  • Traffic Manager's log-forwarding infrastructure has been upgraded to a newer, actively maintained release, keeping the logging stack on a security-supported version and reducing future compatibility and maintenance risks. This is primarily an internal infrastructure change with no impact on default logging behaviour. (EIN-23619)

    However, if you have customized your Fluent Bit configuration, then this update:

    • Upgrades Fluent Bit across Traffic Manager, its associated services (Config UI, Cache, CAM Platform API, and Loader), and the log collector.
    • Migrates all Fluent Bit configuration from the legacy .conf format to the newer YAML-format configuration.
    • Preserves existing log-processing behavior, including access-log parsing, tag-based log routing, multiline parsing, and buffering, so the log format and delivery remain unchanged.

  • Added a pre-upgrade Helm hook that automatically migrates the CAM Platform API service backend endpoint stored in the database when you upgrade an existing 6.2.x cluster to 6.3.0 with helm upgrade. This runs automatically before any workload changes; no manual database update is required. Previously, this endpoint value required a manual update after an upgrade.

    The hook is idempotent and aborts the upgrade if the database migration step fails, so the cluster is not left in a partially upgraded state. Rolling back from 6.3.0 to an earlier version (6.2.1, 6.2.0, 6.1.0, or 6.0.0) doesn't automatically trigger a hook. Revert this data manually using the rollback job shipped in the 6.3.0 chart. (WA-17900)

    Refer to Upgrading 6.2.x → 6.3.0 in the Migration and Upgrade Guide for more information.

  • SDK adapters now require the @AutoService discovery annotation so the Traffic Manager can discover and load them. Run the new migrate-adapter script to scan your adapter project for OSGi-specific code and add this annotation automatically. (EIN-24412)

    Refer to Creating an adapter project for custom authenticator project in the SDK Guide for more information.

  • The Cloud API Management OAuth2 Backend authentication policy now supports a scope parameter when requesting an access token through the authentication service. You can optionally include the scope parameter in Data to make available for pre-processing (PreInput Value) on the Call Transformations page to restrict or specify the exact permissions granted to the token. (EIN-24544)

    Refer to Cloud API Management OAuth2 Backend Authentication Custom Policy Configuration Values for more information.

New
Changes in Boomi Cloud API Management – Local Edition 6.3.0

  • Updated the Local Edition database schema to support a new GraphQL document type, resolving a sync failure between tethered Local Edition clusters and the Boomi Cloud API Management (SaaS). Upgrading from 6.2.x to 6.3.0 requires running the schema upgrade script as part of the upgrade procedure. (EIN-24482)

    Refer to Upgrading 6.2.x → 6.3.0 in the Migration and Upgrade Guide for more information.

  • Updated the CAM Platform API pod's health probes (startup, readiness, liveness) to use port 7000 instead of 8082 with a simplified response payload. The startup and readiness probes now share a single endpoint (/actuator/health/readiness) instead of separate checks (/healthz/startup and /healthz/readiness) used in 6.2.1 and earlier. The response bodies have changed from plain text to JSON with less detailed output than before. No other probe behavior has changed. (WA-18121)

  • Previously, SMTP credentials (smtp.user and smtp.password) were set directly in values.yaml. Starting with this release, SMTP credentials must now be provided as a Kubernetes secret. (EIN-23295)

    Refer to Configuring SMTP and admin emails on LE cluster in the User Guide and Creating and applying an SMTP secret in the Installation Guide for more information.

  • The package-key or api-key segment of request_id in Traffic Manager access logs is no longer masked by default. If you rely on this value being masked, set maskRequestId: true (under global.masking) to restore the previous behavior. If the API key is also passed as a query parameter, add that parameter name to redactionKeys (under global.masking) as well, since masking request_id alone does not redact it from the access log's URL field. (EIN-24425)

    Known Issue

    • When package-key or api-key is masked in access logs, the reporting stack may not derive other reporting fields (such as username) correctly, since this field is the source of truth for that data. This can result in incomplete or incorrect reporting for masked requests. This issue will be fixed in an upcoming release. (EIN-23946)
Fix
We fixed these issues

  • Previously, the Quickstart deployment script accepted only Helm 3.x, so running it with Helm 4 failed. This issue is now resolved. Quickstart now supports Helm 3.15 through 3.17, and Helm 4.0 and later. (EIN-23488)

  • In certain Local Edition clusters, an issue in Traffic Manager access logs caused on-premises API call traffic to be incorrectly counted under the Boomi Cloud API Management (SaaS) gateway's Capacity Centers Report, resulting in inflated call counts. This issue is now resolved. (EIN-23549)

  • Traffic Manager and related pods (CAM Platform API, Loader) failed to restart due to a database lock encountered during liveness probe health checks, causing the pods to become unresponsive. This issue is now resolved. (EIN-22810)

  • Traffic Manager returned intermittent HTTP 504 errors when its idle connection timeout exceeded the backend's keep-alive timeout, causing it to reuse connections the origin had already closed. Traffic Manager now proactively evicts idle connections before the origin closes them. (EIN-24276)

  • When retrieving the WSDL for a SOAP API, the returned endpoint address had the correct hostname but not the correct path, so it did not fully match the API's public endpoint. This issue is now resolved. (EIN-9586)

  • You can now reference a JWT claim nested anywhere in the payload, not just at the root level, when configuring the Key Field Identifier on the Endpoint Key and Method Detection Settings page to identify the client ID for OAuth2 JWT authentication. Previously, in earlier Local Edition versions, only root-level claims were supported for client ID detection, and a nested claim reference would fail authentication. (EIN-24030)

  • Previously, the api_key value was masked only in proxy access logs. Custom or shorter API keys could still appear unmasked in proxy error and warning logs, exposing sensitive credentials in log output. Traffic Manager now masks api_key, password, and secret values consistently across access, error, and warning logs, regardless of key length or whether the key was auto-generated or custom. (EIN-23856)

  • Previously, when an external log destination became temporarily unreachable, it could bring down Traffic Manager, disrupting API traffic. This issue has been resolved. Traffic Manager is now resilient to such scenarios, continuing to serve traffic normally during log destination outages without restarting. (EIN-24206)

  • Previously, running verbose logging continuously could cause Traffic Manager pods to intermittently stop accepting traffic, requiring a manual restart to restore service. Traffic Manager now remains stable under continuous verbose logging, so pods no longer hang or require manual intervention.(EIN-23865)